feat(api): generate and migrate Function REST resources - #758

### AI Summary

Implements the Function metadata slice of #683 by publishing the six CRUD
operations tagged Functions and moving `load_parameters()` retrieval onto the
public REST resources. Function request and response models are also exported
through the public API.

`postFunctionIdInvoke` remains on the specialized invocation path because it
requires proxy routing, streaming, invocation-specific request shaping, and
sync/async behavior outside the generic REST resource contract.

### Migration flow

```text
Before
  load_parameters(id=...) ------> raw GET /v1/function/{id}
  load_parameters(slug=...) ----> raw GET /v1/function

After
  load_parameters(id=...) ------> generated GET /v1/function/{id}
  load_parameters(slug=...) ----> generated GET /v1/function
```

| SDK workflow | Previous wire call | Public REST call |
| --- | --- | --- |
| Load by ID | Raw `GET /v1/function/{id}` | Generated `GET /v1/function/{id}` |
| Load by project and slug | Raw `GET /v1/function` | Generated `GET /v1/function` |
| Function metadata CRUD | No generated resource | `client.openapi.functions` |

| Behavior | Result |
| --- | --- |
| Explicit credentials | Use isolated, cached generated clients without mutating global login |
| Active global login | Reuse the existing generated API client and transport |
| Version and environment | Explicit version continues to take precedence over environment |
| Cache fallback | Preserve local parameter cache fallback for retryable server failures |
| Retry behavior | GET operations are safe reads; writes are not retried |
| Invocation | Continue using the specialized proxy and streaming implementation |
| Type names | Keep the REST model as `Function` and contextually name nested tool-call models |
| Wire keys | Preserve `__schema` without Python name mangling |

Refs #683